【レポート】自動運転のリアルな技術！Mobility TechnologiesがAWSで実現するダイナミックマップへの取り組み #AWSSummit

DA事業本部の春田です。

AWS Summit Online絶賛開催中！ということで、本記事では「CUS-46：Mobility TechnologiesがAWSで実現するダイナミックマップへの取り組み」の内容についてまとめていきます。

セッション情報

• 株式会社 Mobility Technologies 次世代事業部 エンジニア 渡部 徹太郎 氏
• 株式会社 Mobility Technologies 次世代事業部 エンジニア 松浦 慎平 氏

自動運転社会においては、刻一刻と変わる道路状況や高精度な ３ 次元情報を組み合わせたダイナミックマップが必要と言われています。Mobility Technologies は、JapanTaxi や MOV といったタクシー配車アプリの他、次世代のデータビジネスの為、ダイナミックマップ向けに 2 つのプロジェクト行っています。それは「信号情報のリアルタイム配信」と「ドライブレコーダの画像認識による道路情報の自動差分抽出」です。本セッションではこれらのプロジェクトをどのように AWS で実現しているかを解説します。

※セッション動画は以下リンク

アジェンダ

1. Mobility Technologiesとは
2. ダイナミックマップとは
3. 信号情報のリアルタイム配信プロジェクトの紹介
4. 道路情報の自動差分抽出プロジェクトの紹介

Mobility Technologiesとは

• Mission / Vision
  • 移動で人を幸せに。
  • 安心・安全な日本のタクシーを起点に、あらゆる人やモノがストレスなく移動できる社会をつくる
  • モビリティテクノロジーで生活・産業を支え、社会の発展に貢献する
• Mobility Technologiesの取り組み
  • タクシーを基点にして、交通・社会の課題を解決する

• 配車関連事業
  • スマホアプリで、地図で行き先をタップして行き先を指定できる
  • アプリに登録したクレジットカードで自動決済
  • 全国をカバーするタクシーアプリ『JapanTaxi』 → ジャパンタクシー
  • 次世代タクシーアプリ『MOV』　→ DeNAのオートモーティブ事業本部
  • 上二つの会社が合併し、Mobility Technologiesとなった
  • ビジネス需要に特化した『JapanTaxi BUSINESS』
  • 公共施設設置型の『MOV CALL』

• 広告決済事業
  • タクシーアプリ内のキャッシュレス対応（QRコードやIC決済）
  • 車内でのキャッシュレス払いに対応するハードウェア『JapanTaxiタブレット』、『MOV決済機』
  • 後部座席設置型デジタルサイネージによる広告配信
  • 『Tokyo Prime』『Premium Taxi Vision』

• 乗務員向け ソリューション事業
  • タクシーアプリからの配車注文を車両で受けるシステムを開発
  • 乗務員のインバウンド接客をサポートする『JapanTaxi Translator』
    • タブレットに翻訳機能をつけて、外国人のお客様に対応
  • 乗務員採用など、乗務員サポートを多岐にわたって展開

• DRIVE CHART・ドラレコ事業
  • タクシーやトラックなど商用車に向けた、AI活用の交通事故削減支援サービス『DRIVE CHART』
    • ドライブレコーダーで道路や運転手の異常を検知する
  • タクシー運行管理に特化した『JapanTaxiドライブレコーダー』

• 次世代向けR&D事業
  • スマートシティの可能性を探る実証実験・研究開発
    • MaaSの取り組み
    • 自動運転
    • データビジネス → 今回発表するダイナミックマップは、データビジネスの一貫

ダイナミックマップとは

• ダイナミックマップとは
  • 自動運転のために必要な情報の概念
  • 高精度三次元地図情報と、刻一刻と変化する動的データを紐付ける
  • 一番下の基盤に三次元の高性能地図データ
  • その上に車線の本数などの静的な情報
  • その上に交通規制などの準静的情報
  • その上に渋滞や事故情報などの準動的情報
  • 一番上に信号機や歩行者といった動的情報

※出典: ダイナミックマップの概念/定義および、SIP-adusにおける取り組みに関する報告

• Mobility Technologiesのダイナミックマップに向けた取り組み
  • 信号情報のリアルタイム配信プロジェクト
  • 道路情報の自動差分抽出プロジェクト

信号情報のリアルタイム配信プロジェクトの紹介

• 自動運転車向けに信号情報を配信する
  • 自動運転車は様々な情報を複合して、自車両の位置を把握したり、周りの環境を認識したりする
  • カメラによる信号認識の課題
    • 逆光
    • 複数の信号
    • 他車両による遮蔽（死角ができ信号が見えなくなる）

• 信号情報のリアルタイム配信
  • 自動運転車のための信号情報配信
  • 信号機にIoTルーターを設置
  • 4G/5G回線を通して車両に信号情報を届ける
  • 車両はカメラとその情報を複合的に使用して、精度の高い信号認識を行う

• 仕組み
  • 信号情報は灯色のスケジュール情報
    • 今は青、今は赤といった単純な情報ではない
  • 車両は受信したスケジュールと自分の時計で動作
    • 自身の速度や交差点までの距離を計算して判断

• AWS IoTを中心にシステムを構築
  • AWS IoT
    • 高いセキュリティの確保
    • 遅延を減らすためMQTTを採用したい
  • Serverless
    • 実証実験が中心で変更が多い
    • 少人数PRJなので運用負荷を減らしたい
    • 自動運転車の制御に関わるので、高い信頼性が必要

システム構成要素

モノ + α	役割
信号機	信号の灯色のサイクル情報を送信する
自動運転車両	信号情報を受信して、灯色を判断し自動走行する
ビューア	信号の灯色や残り秒数、車両のサブスクライブ状況をモニタリングする

• Pub/Sub + イベント駆動型リアルタイム処理で実現
  • データの送受信 → Pub/Subのメッセージングモデル
  • 内部処理は全てイベント駆動型
  • → 遅延の削減
• 3つの重要なトピック
  • 信号情報を受信するトピック
  • 車両に対して信号情報を配信するトピック（信号機ごとに存在）
  • 車両のイベント情報を配信するトピック
• データの流れ
  • 信号機から情報が配信される（灯色変化時 or 毎秒）
  • 配信された情報はルールに基づいて、Lambdaに渡される
  • DynamoDBにある信号機のメタ情報や、Device shadowに保存されているエラー情報を取得する
  • 車両がサブスクライブしているトピックへ送信する
  • 車両は信号機に近づいた段階で、信号機に対応するトピックをサブスクライブする
  • Viewerは、信号情報と車両情報のトピックをサブスクライブ
  • Viewerは信号機の情報に加え、どの車両がどこの信号機をサブスクライブしているかを把握
    • 車両が信号情報のtopicをサブスクライブしたことをトリガーに、Lambdaを起動して車両情報をpublish
  • 構成はオーソドックスなAWS IoTの使い方だが、Device shadowを使っている点に特徴がある

• Device Shadowとは
  • デバイスの状態を保持できるAWS IoTのサービス
  • 状態の例 → 自動車
    • 今電源が入っているか？
    • ドアは開いているのか？
    • 前照灯がついているのか？
    • ファームウェアのバージョン
  • MQTTの予約されたトピックやREST APIを介して状態を取得/更新
  • デバイスが切断されていても状態を管理できる
  • 情報のギャップを埋めるのにDevice Shadowは活躍する
    • 情報の送信のタイミングのギャップ
    • サブスライブのタイミングの違いによる配信のギャップ

• Device Shadowの使い方1
  • 灯色の情報とともに信号機のエラー情報も配信したい
  • 灯色の情報とエラー情報の送信タイミングが異なるのでDevice Shadowで状態として管理する
  • 灯色情報の送信時にShadowからエラー情報を取得して送信

• Device Shadowの使い方2
  • 車両が信号情報のトピックをサブスクライブしたときに最新の信号情報を送信したい
  • 灯色も信号機の状態としてDevice Shadowで管理
  • AWS IoTのLife cycle eventで車両のSubscribeを検知し、Shadowから現在の状態を送信

• さらなる低遅延を目指して
  • DAX (DynamoDB Accelerator)
    • DynamoDBのインメモリなキャッシュサービス
    • IoTデータ受信の度に必要な静的情報の取得の高速化
    • DynamoDBのキャパシティユニットの節約
  • Lambda: Provisioned Concurrency
    • 同時実行に必要なLambdaインスタンスをあらかじめプロビジョニングできる仕組み
    • Lambdaのスケールアップ時のレイテンシーの悪化を防ぐ
    • IoTデータの送信間隔が長い場合のLambdaのコールドスタートを防ぐ
    • 押しボタン式信号などはコールドスタートになりがち

道路情報の自動差分抽出プロジェクトの紹介

• プロジェクトの概要
  • 課題
    • 自動運転時代においては、地図の更新頻度を上げる必要がある
    • しかし、更新頻度をあげる為には、作業の効率化や費用削減が必要（人手が多い）
  • 解決策
    • 自動的に道路情報の差分を見つけ、地図会社に提供する
    • 車両センサーから車両の位置を特定する
    • ドライブレコーダから道路上の物体を検出する
    • 上2つを組み合わせて、現地の物体の位置を推定し、地図と比較する
    • 差分データをゼンリン社に提供

• 利用技術1: 車両位置を特定する「マップマッチ」
  • ノイズ（ズレ）が多いGPSの位置を道路の線分にマッチさせる

• 利用技術2: 道路上の物体を検出する「機械学習」
  • ディープラーニングが必要

• 利用技術3: 物体の位置を推定する「SLAMの応用」
  • 動画の中から特徴点を見つけ、その点を追跡することで自分がどの位置・どの角度にいるかがわかる

• 全体システム構成
  • 車両は自身の位置情報をアップロードする
  • システムは受け取った位置をマップマッチし、どの道を走行していたかを特定する
  • データがあまりなかった場合は、車両に動画をリクエストして格納する
  • 位置データと動画データで物体検出と物体位置推定を行い、物体の位置関係を特定する
  • 結果を地図と比較し、差分を保存する
  • これらの状態管理は、実行状態管理DBで行う

• 物体検出 → 物体位置推定の処理詳細
  • 動画をS3に格納する
  • 実行状態のDBにAuroraを採用
  • FSx for Lustreで動画をキャッシュ
  • 各種物体検出ワーカにAWS BatchとGPUインスタンス、Spotインスタンスを活用
  • 物体の位置推定にはAWS BatchとCPUインスタンス、Spotインスタンスを使用
  • ポイントは「FSx for Lustre」と「AWS Batch」！

• なぜFXs for Lustreを使うか？
  • 要件
    • 同じ動画に対して、複数のワーカーで異なった物体を認識処理する
  • 問題点
    • S3から直接ダウンロードをする場合、ワーカごとに同じ動画をLocal(EBS)にダウンロードする必要がある
  • 解決策
    • FSx for Lustreを使用して、動画キャッシュ層をはさむ
    • S3からのダウンロードを1回にでき、システム全体のIOスループットを向上できる
    • ワーカはLinux FSにアクセスするだけでよく開発が簡単
    • aws s3 cpしなくてよい。直接ファイルリードできる

• なぜAWS Batchを使うのか？
  • 要件
    • 画像データはファイル化するとサイズが大きくなってしまうので、メモリ上で処理したい
    • 不必要な画像（車両が止まっている時の動画）はフィルタリングで除外したい
    • 物体検出失敗の時には、フレーム間で補間したい
  • 問題点
    • 物体検出ワーカーで行う処理は、典型的な機械学習のワークロードではない
    • 機械学習ではない計算が要求されるので、カスタムコンテナが必要
  • 解決策
    • カスタムコンテナの分散バッチ実行環境の選択肢は4つ
    • まず、運用工数の観点からECSとEKSは候補から外した
    • 今回はSageMakerのフレームワークが活用できない/制約が大きいため、AWS Batchを選択

※まだ設計段階、これから実装していく

まとめ

• 自動運転社会ではダイナミックマップが必要
• Mobility Technologiesでは2つのプロジェクトを実施
• 信号情報のリアルタイム配信プロジェクト
  • AWS IoTを用いたPub/Subメッセージングとイベント駆動リアルタイム処理で、低遅延での信号情報配信を実現
• 道路情報の自動差分抽出プロジェクト
  • FSx for Lustreを大量動画データのキャッシュに利用
  • AWS Batchを用いて、機械学習やアルゴリズム計算が混在する分散バッチ処理を実現